Java Business Integration

F or as long as I can remember, an argument has been making the rounds in distributed computing circles about how best to define interfaces for distributed elements. Some advocate the use of an interface definition language (IDL), whereas others prefer to use programming languages directly. (There are even those who prefer to avoid explicitly defining interfaces altogether, but I’ll ignore that position for now.) Not surprisingly, the Java community has traditionally sided with the programming language approach — arguing, in part, that IDLs are too far removed from the languages that developers use for implementation, and that the resulting mismatch often makes it difficult to map between the two. In practice, this means that either the IDL forces the developer to use an unnatural programming style, or the interface developer is stuck defining cumbersome interfaces to match the programming language. One of the most blatant examples I’ve personally experienced of this impedance mismatch is the Corba Java-to-IDL reverse mapping,1 which is intended to let developers define Corba interfaces in pure Java and map the results into Corba IDL. Although the approach produces reasonable results for systems defined entirely in Java, the resulting IDL is strange and overly complex, creating further complications if it must subsequently be mapped to a language other than Java. The desire to avoid such mismatches has led, in part, to the development of various approaches centered on “plain ol’ Java objects” (POJOs). One such example is the Hibernate framework (www. hibernate.org), which provides developers with transparent support for storing Java objects in relational databases. Rather than relying on detailed component interfaces or complex object hierarchies characteristic of older frameworks, the POJO approach lets developers focus on producing normal Java code, while relying on tools and reflective infrastructure to transparently adapt that code for persistence, security, transactions, and other orthogonal qualities and capabilities. The POJO approach works well if you’re a Java programmer developing a pure Java system, but what happens when such purity isn’t possible? The world of enterprise integration is often an “impure” place in which heterogeneous networks include everything from mainframes to blades running an amalgam of operating systems and applications. Given that Java is unlikely to be the only language in use in such settings, there’s a clear need to step above individual programming languages and define services at a more abstract level that applies equally to various scripting, transformation, and programming languages.